Release 10.1A: OpenEdge Getting Started:
Core Business Services

Trusted authentication systems and domains

A trusted authentication system is one that is trusted by a system or application to correctly implement the security processes necessary to ensure that authenticated user accounts are used only by their owners. The trusted authentication system is also expected to assure that it cannot be spoofed into using falsified credentials.

The level of security establishes the amount of trust that may be used to protect application operations and data. Trusted systems have many levels of trust, and an application should use the level of trust appropriate for the value of the application data to the end user. For example, a system based on user names and passwords might be trusted to provide enough security for noncritical information such as warehouse inventory but would not provide enough security to be trusted to protect a company’s financial information.

The OpenEdge database’s sole built-in trusted authentication system is the _User table; once a user is authenticated to the _User table, authorization is administered based on the table and field CAN-* permissions.

Note: Table and field CAN-* permissions use a database’s current user ID, which can originate from either the built-in _User table accounts or an external authentication system.

An external trusted authentication system requires you to set up a trust relationship between a 4GL application that has its own system user accounts and OpenEdge so that OpenEdge knows it can trust the user account authentication performed by the 4GL application. In OpenEdge, each external authentication system type must be defined before it can be used. That definition involves assigning a common, or logical, name that clearly defines it. For example, LDAP would be a type name for the support a 4GL application would provide to use an external LDAP directory service. 4GL-Local may be a type name that refers to a 4GL application’s procedures that support its own user account tables.

Each instance, or physical implementation, of a trusted authentication system type is known as a trusted authentication domain. After you create an authentication system type, you configure a domain, and provide a name, description, the domain’s access code, and any additional comments you want. The name you provide for the domain is the logical name that will be used by OpenEdge to locate the domain’s configuration at run time to validate the origin and authenticity of the user account that was authenticated by the 4GL’s authentication system procedures.

When you create a domain, also known as an instance of an authentication system, you define its access code. The access code is stored as an encrypted phrase to prevent its being used to impersonate the legitimate 4GL authentication system procedures. The access code functions as a shared secret, much like a password, between the 4GL procedures that implement the authentication system domain and OpenEdge’s Progress session and/or database connections.

After a successful user authentication, the 4GL procedures create the login-session token and certify it by performing a seal operation using the domain’s shared secret. Sealing can be likened to the historical practice of sealing an envelope with a wax seal, imprinted with a private stamp, when dispatching important information. If the seal was recognized by the recipient, the recipient knew from whom the envelope and its contents originated. If the seal was unbroken, the recipient also knew that the envelope’s contents had not been tampered with. That same concept exists in today’s security world, and OpenEdge uses it in the trust relationship between 4GL-implemented user authentication systems and the OpenEdge run-time system.